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Identity Representation for RSVP 


Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2001). All Rights Reserved. 
Abstract 


This document describes the representation of identity information in 
POLICY DATA object for supporting policy based admission control in 
the Resource ReSerVation Protocol (RSVP). The goal of identity 
representation is to allow a process on a system to securely identify 
the owner and the application of the communicating process (e.g., 
user id) and convey this information in RSVP messages (PATH or RESV) 
in a secure manner. We describe the encoding of identities as RSVP 
policy element. We describe the processing rules to generate 
identity policy elements for multicast merged flows. Subsequently, 
we describe representations of user identities for Kerberos and 
Public Key based user authentication mechanisms. In summary, we 
describe the use of this identity information in an operational 
setting. 


This memo corrects an RSVP POLICY_DATA P-Type codepoint assignment 
error and a field size definition error in ErrorValue in RFC 2752. 
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1. Conventions used in this document 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC 2119]. 


2. Introduction 


RSVP [RFC 2205] is a resource reservation setup protocol designed for 


an integrated services Internet [RFC 1633].  RSVP is used by a host 
to request specific quality of service (QoS) from the network for 
particular application data streams or flows.  RSVP is also used by 


routers to deliver QoS requests to all nodes along the path(s) of the 
flows and to establish and maintain state to provide the requested 
Service.  RSVP requests will generally result in resources being 
reserved in each node along the data path.  RSVP allows particular 
users to obtain preferential access to network resources, under the 
control of an admission control mechanism. Permission to make a 
reservation is based both upon the availability of the requested 
resources along the path of the data and upon satisfaction of policy 
rules. Providing policy based admission control mechanism based on 
user identity or application is one of the prime requirements. 


In order to solve these problems and implement identity based policy 
control it is required to identify the user and/or application making 
a RSVP request. 


This document proposes a mechanism for sending identification 
information in the RSVP messages and enables authorization decisions 
based on policy and identity. 


We describe the authentication policy element (AUTH DATA) contained 
in the POLICY DATA object. User process can generate an AUTH DATA 
policy element and gives it to RSVP process (service) on the 
originating host.  RSVP service inserts AUTH DATA into the RSVP 
message to identify the owner (user and/or application) making the 
request for network resources. Network elements, such as routers, 
authenticate request using the credentials presented in the AUTH DATA 
and admit the RSVP message based on admission policy. After a 
request has been authenticated, first hop router installs the RSVP 
state and forwards the new policy element returned by the Policy 
Decision Point (PDP) [POL-FRAME]. 
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3. Policy Element for Authentication Data 


3.1 Policy Data Object Format 


October 2001 


POLICY DATA objects contain policy information and are carried by 
RSVP messages. A detail description of the format of POLICY DATA 
object can be found in "RSVP Extensions for Policy Control" [POL- 
EXT]. 


3.2 Authentication Data Policy Element 


In this section, we describe a policy element (PE) called 
authentication data (AUTH DATA).  AUTH DATA policy element contains a 
list of authentication attributes. 


Tacne renan 4------------- 4------------- ———ÓÁÁ— + 

| Length | P-Type = Identity Type | 

4------------- 4------------- 4------------- 4------------- + 

// Authentication Attribute List // 

PisSs ese Seaas See atses Sees Sessa s Sas eSe see ee Ss S2SSe—S5ese= + 
Length 


The length of the policy element (including the Length and P-Type) 
is in number of octets (MUST be a multiple of 4) and indicates the 
end of the authentication attribute list. 


P-Type (Identity Type) 
Type of identity information contained in this Policy Element 
supplied as the Policy element type (P-type). The Internet 
Assigned Numbers Authority (IANA) acts as a registry for policy 
element types for identity as described in the [POL-EXT]. 
Initially, the registry contains the following P-Types for 


identity: 
2 AUTH USER Authentication scheme to identify users 
3 AUTH APP Authentication scheme to identify 


applications 
Authentication Attribute List 


Authentication attributes contain information specific to 
authentication method and type of AUTH DATA. The policy element 
provides the mechanism for grouping a collection of authentication 
attributes. 
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3.3 Authentication Attributes 


Authentication attributes MUST be encoded as a multiple of 4 octets, 
attributes that are not a multiple of 4 octets long MUST be padded to 
a 4-octet boundary. 


4-------- 4-------- 4-------- 4-------- + 
| Length | A-Type |SubType | 
4-------- 4-------- 4-------- 4-------- + 
| Value 
goes 4-------- 4-------- 4-------- + 
Length 


The length field is two octets and indicates the actual length of 
the attribute (including the Length and A-Type fields) in number 

of octets. The length does not include any bytes padding to the 

value field to make the attribute multiple of 4 octets long. 


A-Type 
Authentication attribute type (A-Type) field is one octet. IANA 
acts as a registry for A-Types as described in the section 8, 
IANA Considerations. Initially, the registry contains the 
following A-Types: 


1 POLICY LOCATOR Unique string for locating the 
admission policy (such as X.500 DN 
described in [RFC 1779]). 


2 CREDENTIAL User credential such as Kerberos 
ticket, or digital certificate. 
Application credential such as 
application ID. 


3 DIGITAL_SIGNATURE Digital signature of the 
authentication data policy element. 


4 POLICY ERROR OBJECT Detailed information on policy 
failures. 


SubType 
Authentication attribute sub-type field is one octet. Value of 


SubType depends on A-type. 


Value: 
The value field contains the attribute specific information. 


Yadav, et al. Standards Track [Page 4] 


RFC 3182 Identity Representation for RSVP October 2001 


3.3.1 Policy Locator 


POLICY LOCATOR is used to locate the admission policy for the user or 
application. Distinguished Name (DN) is unique for each User or 
application hence a DN is used as policy locator. 


4------- 4------- 4------- 4------- t 
| Length |A-Type |SubType| 
4------- 4------- 4------- 4------- + 
| OctetString 

4------- 4£------- 4------- 4-------- 
Length 


Length of the attribute, which MUST be »- 4. 


A-Type 
POLICY LOCATOR 


SubType 
Following sub types for POLICY LOCATOR are defined.  IANA acts as 
a registry for POLICY LOCATOR sub types as described in the 
section 8, IANA Considerations. Initially, the registry contains 
the following sub types for POLICY LOCATOR: 


1 ASCII DN OctetString contains the X.500 DN as 
described in the RFC 1779 as an ASCII 
string. 

2 UNICODE DN OctetString contains the X.500 DN described 


in the RFC 1779 as an UNICODE string. 


3 ASCII DN ENCRYPT OctetString contains the encrypted X.500 
DN. The Kerberos session key or digital 
certificate private key is used for 
encryption. For Kerberos encryption the 
format is the same as returned from 
gss seal [RFC 1509]. 


4  UNICODE DN ENCRYPT OctetString contains the encrypted UNICODE 
X.500 DN. The Kerberos session key or 
digital certificate private key is used for 
encryption. For Kerberos encryption the 
format is the same as returned from 
gss seal [RFC 1509]. 


OctetString 
The OctetString field contains the DN. 
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3.3.2 Credential 


CREDENTIAL indicates the credential of the user or application to be 
authenticated. For Kerberos authentication method the CREDENTIAL 
object contains the Kerberos session ticket. For public key based 
authentication this field contains a digital certificate. 


A summary of the CREDENTIAL attribute format is shown below. The 
fields are transmitted from left to right. 


4£------- 4------- 4------- 4------- t 
| Length |A-Type |SubType| 
4------- 4------- 4------- 4------- t 
| OctetString 

4------- 4£------- 4------- 4-------- 
Length 


Length of the attribute, which MUST be »- 4. 


A-Type 
CREDENTIAL 

SubType 
IANA acts as a registry for CREDENTIAL sub types as described in 
the section 8, IANA Considerations. Initially, the registry 
contains the following sub types for CREDENTIAL: 


1 ASCII ID OctetString contains user or application 
identification in plain ASCII text string. 


2 UNICODE ID OctetString contains user or application 
identification in plain UNICODE text string. 


3 KERBEROS_TKT OctetString contains Kerberos ticket. 


4 X509 V3 CERT OctetString contains X.509 V3 digital 
certificate [X.509]. 


5 PGP CERT OctetString contains PGP digital certificate. 


OctetString 
The OctetString contains the user or application credential. 
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3.3.3 Digital Signature 


The DIGITAL SIGNATURE attribute MUST be the last attribute in the 
attribute list and contains the digital signature of the AUTH DATA 
policy element. The digital signature signs all data in the 

AUTH DATA policy element up to the DIGITAL SIGNATURE. The algorithm 
used to compute the digital signature depends on the authentication 
method specified by the CREDENTIAL SubType field. 


A summary of DIGITAL SIGNATURE attribute format is described below. 


4------- 4------- 4------- 4------- t 
| Length |A-Type |SubType| 
4------- 4------- 4------- 4------- t 
| OctetString 

4------- 4------- 4------- 4-------- 
Length 


Length of the attribute, which MUST be »- 4. 


A-Type 
DIGITAL SIGNATURE 


SubType 
No sub types for DIGITAL SIGNATURE are currently defined. This 
field MUST be set to 0. 


OctetString 
OctetString contains the digital signature of the AUTH DATA. 


3.3.4 Policy Error Object 


This attribute is used to carry any specific policy control errors 
generated by a node when processing/validating an Authentication Data 
Policy Element. When a RSVP policy node (local policy decision point 
or remote PDP) encounters a request that fails policy control due to 
its Authentication Policy Element, it SHOULD add a POLICY ERROR CODE 
containing additional information about the reason the failure 
occurred into the policy element. This will then cause an 
appropriate PATH ERROR or RESV ERROR message to be generated with the 
policy element and appropriate RSVP error code in the message, which 
is returned to the request's source. 


The AUTH DATA policy element in the PATH or RSVP message SHOULD not 
contain the POLICY ERROR OBJECT attribute. These are only inserted 
into PATH ERROR and RESV ERROR messages when generated by policy 
aware intermediate nodes. 
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4---------- 4---------- 4---------- 4---------- + 
| Length | A-Type | SubType | 
4---------- 4---------- 4---------- 4---------- + 
| 0 (Reserved) | ErrorValue 
4---------- 4---------- 4---------- 4---------- + 
| OctetString 

4---------- 4---------- 4---------- 4---------- + 
Length 


Length of the attribute, which MUST be >= 8. 


A-Type 
POLICY_ERROR_CODE 


SubType 
No sub types for POLICY_ERROR_CODE are currently defined. This 
field MUST be set to 0. 


ErrorValue 
A 16-bit bit code containing the reason that the policy decision 
point failed to process the policy element. IANA acts as a 
registry for ErrorValues as described in section 8, IANA 
Considerations. Following values have been defined. 
1 ERROR NO MORE INFO No information is available. 
2 UNSUPPORTED CREDENTIAL TYPE This type of credentials is 


not supported. 


3  INSUFFICIENT PRIVILEGES The credentials do not have 
sufficient privilege. 


4 EXPIRED CREDENTIAL The credential has expired. 
5 . IDENTITY CHANGED Identity has changed. 
OctetString 


The OctetString field contains information from the policy 
decision point that MAY contain additional information about the 
policy failure. For example, it may include a human-readable 
message in the ASCII text. 


Authentication Data Formats 


Authentication attributes are grouped in a policy element to 
represent the identity credentials. 
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4.1 Simple User Authentication 


In simple user authentication method the user login ID (in plain 
ASCII or UNICODE text) is encoded as CREDENTIAL attribute. A summary 
of the simple user AUTH DATA policy element is shown below. 


4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length | P-type = AUTH_USER 
4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length |POLICY LOCATOR| SubType | 
4+-------------- 4R-------------- 4R-------------- 4R-------------- * 
| OctetString (User's Distinguished Name) 

4R-------------- 4R-------------- 4R-------------- 4R-------------- * 
| Length | CREDENTIAL | ASCII ID 
4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| OctetString (User’s login ID) 

4+-------------- 4+-------------- 4+-------------- 4+-------------- + 


4.2 Kerberos User Authentication 


Kerberos [RFC 1510] authentication uses a trusted third party (the 
Kerberos Distribution Center - KDC) to provide for authentication of 
the user to a network server. It is assumed that a KDC is present 
and both host and verifier of authentication information (router or 
PDP) implement Kerberos authentication. 


A summary of the Kerberos AUTH_DATA policy element is shown below. 


4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length | P-type = AUTH_USER 
4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length |POLICY_LOCATOR| SubType | 
4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| OctetString (User’s Distinguished Name) 

4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length | CREDENTIAL | KERBEROS TKT 
4R-------------- 4R-------------- 4R-------------- 4R-------------- * 
| OctetString (Kerberos Session Ticket) 

4R-------------- 4R-------------- 4R-------------- 4R-------------- + 


4.2.1. Operational Setting using Kerberos Identities 


An RSVP enabled host is configured to construct and insert AUTH_DATA 
policy element into RSVP messages that designate use of the Kerberos 
authentication method (KERBEROS_TKT). Upon RSVP session 
initialization, the user application contacts the KDC to obtain a 
Kerberos ticket for the next network node or its PDP. A router when 
generating a RSVP message contacts the KDC to obtain a Kerberos 
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ticket for the next hop network node or its PDP. The identity of the 
PDP or next network hop can be statically configured, learned via 
DHCP or maintained in a directory service. The Kerberos ticket is 
sent to the next network node (which may be a router or host) in a 
RSVP message. The KDC is used to validate the ticket and 
authentication the user sending RSVP message. 


4.3 Public Key based User Authentication 


In public key based user authentication method digital certificate is 
encoded as user credentials. The digital signature is used for 
authenticating the user. A summary of the public key user AUTH DATA 
policy element is shown below. 


4R-------------- 4-------------- 4R-------------- 4R-------------- * 
| Length | P-type - AUTH USER 
4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length |POLICY_LOCATOR| SubType | 
4+-------------- 4R-------------- 4R-------------- 4R-------------- + 
| OctetString (User’s Distinguished Name) 

4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length | CREDENTIAL | SubType 
4R-------------- 4R-------------- 4R-------------- 4R-------------- + 
| OctetString (User’s Digital Certificate) 

4R-------------- 4R-------------- 4R-------------- 4R-------------- * 
| Length [DIGITAL SIGN. | O 
4R-------------- 4R-------------- 4R-------------- 4R-------------- * 
| OctetString (Digital signature) 

4+-------------- 4R-------------- 4R-------------- 4R-------------- + 


4.3.1. Operational Setting for public key based authentication 


Public key based authentication assumes following: 


RSVP service requestors have a pair of keys (private key and 
public key). 


- Private key is secured with the user. 
- Public keys are stored in digital certificates and a trusted 
party, certificate authority (CA) issues these digital 


certificates. 


- The verifier (PDP or router) has the ability to verify the 
digital certificate. 
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RSVP requestor uses its private key to generate DIGITAL SIGNATURE. 
User Authenticators (router, PDP) use the user's public key (stored 
in the digital certificate) to verify the signature and authenticate 
the user. 


4.4 Simple Application Authentication 
The application authentication method encodes the application 


identification such as an executable filename as plain ASCII or 
UNICODE text. 


4R---------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length | P-type = AUTH_APP 

4+---------------- 4R-------------- 4R-------------- 4R-------------- + 
| Length |POLICY_LOCATOR| SubType | 
4+---------------- 4R-------------- 4R-------------- 4R-------------- * 


| OctetString (Application Identity attributes in 
| the form of a Distinguished Name) 


+---------------- +-------------- +-------------- +-------------- + 
| Length | CREDENTIAL | ASCII_ID 
+---------------- +-------------- +-------------- +-------------- + 
| OctetString (Application Id, e.g., vic.exe) 

+---------------- 4R-------------- 4R-------------- 4R-------------- * 


5. Operation 


+----- + +----- + 
| PDP |------- + | PDP 
4----- * MEM LL LZ nr nn 4----- * 
| : | 

+-------- + : Transit : t= ==SsS= + 

+----| Router |------ : Network : ------- | Router |--+ 

| +-------—- + : : 4R------- + | 

Host A B C D 


Figure 1: User and Application Authentication using AUTH_DATA PE 


Network nodes (hosts/routers) generate AUTH_DATA policy elements, 
contents of which are depend on the identity type used and the 
authentication method used. These generally contain authentication 
credentials (Kerberos ticket or digital certificate) and policy 
locators (which can be the X.500 Distinguished Name of the user or 
network node or application names). Network nodes generate AUTH DATA 
policy element containing the authentication identity when making the 
RSVP request or forwarding a RSVP message. 
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Network nodes generate user AUTH DATA policy element using the 
following rules: 


1. For unicast sessions the user policy locator is copied from the 
previous hop. The authentication credentials are for the current 
network node identity. 


2. For multicast messages the user policy locator is for the current 
network node identity. The authentication credentials are for the 
current network node. 


Network nodes generate application AUTH DATA policy element using the 
following rules: 


1. For unicast sessions the application AUTH DATA is copied from the 
previous hop. 


2. For multicast messages the application AUTH DATA is either the 
first application AUTH DATA in the message or chosen by the PDP. 


6. Message Processing Rules 
6.1 Message Generation (RSVP Host) 


An RSVP message is created as specified in [RFC 2205] with following 
modifications. 


1. RSVP message MAY contain multiple AUTH DATA policy elements. 


2. Authentication policy element (AUTH DATA) is created and the 
IdentityType field is set to indicate the identity type in the 
policy element. 


- DN is inserted as POLICY LOCATOR attribute. 


- Credentials such as Kerberos ticket or digital certificate are 
inserted as the CREDENTIAL attribute. 


3. POLICY DATA object (containing the AUTH DATA policy element) is 
inserted in the RSVP message in appropriate place. If INTEGRITY 
object is not computed for the RSVP message then an INTEGRITY 
object SHOULD be computed for this POLICY DATA object, as 
described in the [POL EXT], and SHOULD be inserted as a Policy 
Data option. 
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6.2 Message Reception (Router) 


RSVP message is processed as specified in [RFC 2205] with following 
modifications. 


1. If router is not policy aware then it SHOULD send the RSVP message 
to the PDP and wait for response. If the router is policy unaware 
then it ignores the policy data objects and continues processing 
the RSVP message. 


2. Reject the message if the response from the PDP is negative. 
3. Continue processing the RSVP message. 
6.3 Authentication (Router/PDP) 


1. Retrieve the AUTH DATA policy element. Check the PE type field 
and return an error if the identity type is not supported. 


2. Verify user credential 


- Simple authentication: e.g., Get user ID and validate it, or 
get executable name and validate it. 


- Kerberos: Send the Kerberos ticket to the KDC to obtain the 
session key. Using the session key authenticate the user. 


- Public Key: Validate the certificate that it was issued by a 
trusted Certificate Authority (CA) and authenticate the user or 
application by verifying the digital signature. 


7. Error Signaling 


If PDP fails to verify the AUTH DATA policy element then it MUST 
return policy control failure (Error Code = 02) to the PEP. The 
error values are described in [RFC 2205] and [POL-EXT]. Also PDP 
SHOULD supply a policy data object containing an AUTH DATA Policy 
Element with A-Type-POLICY ERROR CODE containing more details on the 
Policy Control failure (see section 3.3.4). The PEP will include 
this Policy Data object in the outgoing RSVP Error message. 


8. IANA Considerations 
Following the policies outlined in [IANA-CONSIDERATIONS], Standard 


RSVP Policy Elements (P-type values) are assigned by IETF Consensus 
action as described in [POL-EXT]. 
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P-Type AUTH USER is assigned the value 2.  P-Type AUTH APP is 
assigned the value 3. 


Following the policies outlined in [IANA-CONSIDERATIONS], 
authentication attribute types (A-Type) in the range 0-127 are 
allocated through an IETF Consensus action, A-Type values between 
128-255 are reserved for Private Use and are not assigned by IANA. 


A-Type POLICY LOCATOR is assigned the value 1.  A-Type CREDENTIAL is 
assigned the value 2.  A-Type DIGITAL SIGNATURE is assigned the value 
3. A-Type POLICY ERROR OBJECT is assigned the value 4. 


Following the policies outlined in [IANA-CONSIDERATIONS], 

POLICY LOCATOR SubType values in the range 0-127 are allocated 
through an IETF Consensus action, POLICY LOCATOR SubType values 
between 128-255 are reserved for Private Use and are not assigned by 
IANA. 


POLICY LOCATOR SubType ASCII DN is assigned the value 1, SubType 
UNICODE DN is assigned the value 2, SubType ASCII DN ENCRYPT is 
assigned the value 3 and SubType UNICODE DN ENCRYPT is assigned the 
value 4. 


Following the policies outlined in [IANA-CONSIDERATIONS], CREDENTIAL 
SubType values in the range 0-127 are allocated through an IETF 
Consensus action, CREDENTIAL SubType values between 128-255 are 
reserved for Private Use and are not assigned by IANA. 


CREDENTIAL SubType ASCII ID is assigned the value 1, SubType 
UNICODE ID is assigned the value 2, SubType KERBEROS TKT is assigned 
the value 3, SubType X509 V3 CERT is assigned the value 4, SubType 
PGP CERT is assigned the value 5. 


Following the policies outlined in [IANA-CONSIDERATIONS], ErrorValues 
in the range 0-32767 are allocated through an IETF Consensus action, 

ErrorValues between 32768-65535 are reserved for Private Use and are 

not assigned by IANA. 


ErrorValue ERROR NO MORE INFO is assigned the value 1, 

UNSUPPORTED CREDENTIAL TYPE is assigned the value 2, 

INSUFFICIENT PRIVILEGES is assigned the value 3, EXPIRED CREDENTIAL 
is assigned the value 4, and IDENTITY CHANGED is assigned the value 
5% 
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9. Security Considerations 


The purpose of this memo is to describe a mechanism to authenticate 
RSVP requests based on user identity in a secure manner.  RSVP 
INTEGRITY object is used to protect the policy object containing user 
identity information from security (replay) attacks. Combining the 
AUTH DATA policy element and the INTEGRITY object results in a secure 
access control that enforces authentication based on both the 
identity of the user and the identity of the originating node. 


Simple authentication does not contain credential that can be 
securely authenticated and is inherently less secured. 


The Kerberos authentication mechanism is reasonably well secured. 


User authentication using a public key certificate is known to 
provide the strongest security. 
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13. Full Copyright Statement 
Copyright (C) The Internet Society (2001). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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